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ABSTRACT 



There is provided an event management system and a 
storage media for identifying and logging event information 
for a plurality of loosely coupled subsystems. The event 
management system and the storage media include an appli- 
cation for reporting an event message in response to an 
occurrence of a particular event, and an event logging 
routine, responsive to receiving the error message, for 
identifying a source of the error message and for obtaining 
detailed error information for the error message at a time 
frame when the particular event occurs. In addition, the 
event management system and storage media include an 
event viewer for viewing the detailed error information. 

13 Claims, 5 Drawing Sheets 
-30 
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ERROR MANAGEMENT SYSTEM FOR 
SUPPORTING THE IDENTIFICATION AND 
LOGGING OF ERROR MESSAGES 

The present invention relates generally to systems that 5 
provide their users with explanations or descriptions for 
errors that occur during their operation. More particularly, 
the present invention relates to an error management system 
for supporting the identification and logging of error mes- 
sages for a client/server environment. 1Q 

BACKGROUND OF THE INVENTION 

Existing operating systems include error handling tools 
that identify and log errors that occur during the operation of 
the operating systems and provide a user with the ability to 
view the logged errors. Although most applications running 15 
in the operating system's environment provide error mes- 
sages when errors occur, these error messages are often 
technical in nature and may not be easily understood by the 
user. Therefore, the error handling tools not only identify 
and log these errors but, in addition, they describe the errors 2 o 
to the user in an easily comprehensible format. For example, 
the Windows NT® operating system by Microsoft Corpo- 
ration includes an event log that collects error messages 
from applications, device drivers and the operating system 
itself to a common location that the user can access. The 25 
Windows NT® operating system also includes an event 
viewer that permits the user to view the error messages in the 
order of their occurrences. 

The error handling tools of existing operating systems 
work fine for a self-contained environment, but do not 30 
operate well in a client/server environment having one or 
more client applications and service providers. In particular, 
the client application has the burden of understanding the 
error messages and to log a meaningful text for the message, 
but this task is difficult to manage in a client/server envi- 35 
ronment. If an error is encountered when the client appli- 
cation requests a service from a particular service provider, 
the service provider returns an error code that must be 
interpreted by the client application. 

For existing error handling tools, the client application 40 
must have advance knowledge of the possible types of 
service failures. Otherwise, the client application would not 
be able to provide meaningful information regarding the 
nature of the error. This poses problems in a client-server 
environment because the client application and applications 45 
of the service providers are loosely coupled and developed 
independently, and it is not practical to change an applica- 
tion as its underlying service provider evolves. It is, 
therefore, difficult for a client application to obtain mean- 
ingful information for an error message within a client/ 50 
server environment. 

The present invention resolves the above problems by 
providing a mechanism for a client application that identifies 
the source of a service error and obtains detailed error 
information at the time the error occurs. In particular, the 55 
mechanism accesses the error message information specific 
to the service that encounters the error and, then, reports that 
information as part of its error handling operation. The 
present invention also functions in a plurality of nested 
subsystems in which a subsystem that detects a particular 60 
problem is identified among a group of subsystems that are 
called in a nested manner. Accordingly, the present invention 
automatically handles the operation of reporting events 
whose source subsystem is different from that of the report- 
ing subsystem without requiring the reporting subsystem to 65 
have advance knowledge of the possible errors that could be 
encountered. 
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SUMMARY OF THE INVENTION 

The present invention is an event management system and 
a storage media for identifying and logging event informa- 
tion for a plurality of subsystems which, in brief summary, 
comprises a means for reporting an event message in 
response to an occurrence of a particular event; a means, 
responsive to receiving the error message, for identifying a 
source of the error message, and a means for obtaining 
detailed error information for the error message at a time 
frame when the particular event occurs. The event manage- 
ment system and storage media also comprise a means for 
providing the detailed error information to an event viewer. 

The event message corresponds to an event type that 
includes at least one event type selected from the group 
consisting of an information event type, a warning event 
type and an error event type. More specifically, the event 
type is an error event type used to report a non-recoverable 
problem. 

The event management system includes a service routine 
for receiving logging information from a particular sub- 
system and handling a logging operation of another 
subsystem, and a definition table that defines a relationship 
between an identification of a particular subsystem and a 
message catalog associated with the particular subsystem. In 
addition, the message catalog includes a special event mes- 
sage for identifying logging information that does not origi- 
nate from the particular subsystem. 

The foregoing and still further objects and advantages of 
the present invention will be more apparent from the fol- 
lowing detailed explanation of the preferred embodiments of 
the invention in connection with the accompanying draw- 
ings: 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of an error handling system of 
the prior art; 

FIG. 2 is a block diagram of the preferred error manage- 
ment system in accordance with the present invention; 

FIG. 3 is a flow diagram of the facility code I.D. devel- 
opment procedure; and 

FIGS. 4a and 4b are flow diagrams of the operation of the 
event logger routine of FIG. 2. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The present invention is a system for identifying the 
source of a service error and obtaining detailed error infor- 
mation when the error occurs. The error message informa- 
tion of the service error is accessed and reported as part of 
the system's error handling operation. Thus, the error infor- 
mation is available to the user when, at a subsequent time, 
the user requests the error information using an event viewer 
or the like. 

Three basic types of events, namely information, warn- 
ings and errors, are logged for every application and oper- 
ating system component. An information event is typically 
used to indicate the occurrence of an important activity, a 
warning event is used to indicate some kind of recoverable 
anomaly, and an error event is used to report a non- 
recoverable problem. Standard information is associated 
with each event type, and event-specific information may 
also be added. 

Referring to FIG. 1, there is shown an error handling 
system 10 of the prior art that includes logging functions that 
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provide decoupled reporting services. Error handling system log. The registry provides a map for the subsystem ID to 

10 includes an application 12, an event logger 14 and an source name. In addition, each subsystem 36 has a corre- 

event log 16. Application 12 is a self-contained application sponding error message catalog 40 containing information 

and, thus, is not part of a client/server environment. that may be logged to report errors that occur within its 

Generally, application 12 registers with event logger 14 and, 5 processing. Each message catalog 40 also has a special 

then, receives a handle from the operating system which message, i.e., special event ID, used to identify cases where 

application 12 uses to identify itself when sending messages. the information being logged is from a different subsystem 

As the application runs, it may encounter errors which it 36 and, therefore, is not contained within its own message 

needs to report using the event logging service. To do so, it catalog 40. Also, , an event log 42 collects log information 

sends a message to the event logger 14 which contains the 10 from event logger 34. 

identifier to a text message in its message catalog 20. Event Accordingly, the preferred embodiment 30 enables 

logger 14 then records the error in event log 16. Accordingly, loosely coupled client/server applications to perform event 

throughout the operation of application 12, error codes that logging with a service provider or subsystem 36 by captur- 

are identified by application 12 are recorded in event log 16. i ng the i r error mesS age at the time the error occurs and using 

To the contrary, conventional error message system 15 their subsystem ID to record the message. In particular, 
included message catalogs that only contained event mes- event logging routine 32 receives the event ID from sub- 
sages that the application had knowledge about in advance mitter program 34 and passes the subsystem ID of submitter 
and had prepared for in advance. This necessity to have program 34 and necessary information, i.e., string message, 
advance knowledge of the possible errors and to have set up for the event. First, submitter program 34 registers its 
a message catalog accordingly is one of the limitations 20 subsystem ID to the service routine. After that, if an error 
which the present invention overcomes. occurs, the submitter program 34 passes the error identifi- 

As shown in FIG. 1, an event viewer 18 may be used to cation that includes the subsystem ID of subsystem 36 and 

read and filter events by event type, event category, and/or i* s associated event ID in order to log the event, 

event source. The event source is a name describing the Event logging routine 32 checks the passed subsystem ID. 

module that logged the event and is used to identify an 25 If the system ID matches that of the submitting program or 

application message catalog 20 which supplies message text subsystem 36, then the error information is resident within 

to event viewer 18. Finally, the message text is expanded and the subsystem's error message file and can be logged using 

displayed at a terminal 20, such as a personal computer or normal error logging message calls. If, however, the error 

workstation, by event viewer 18. Also, a registry 22 com- information shows that the error is associated with a differ- 

municates information to event viewer 18 that maps the 30 ent subsystem 36, event logging routine 32 accesses another 

event source to application message catalog 20. subsystem's message catalog 40 using its definition table, 

Although error handling system 10 shown in FIG. 1 works retrieves the message for the passed event ID from the other 

fine for self-contained applications, it does not work well in subsystem's message catalog 40, and logs the special event 

client/server environments or nested subsystem situations. ID above along with specifying another subsystem's ID and 

In particular, it is not practical to have application 12 track message as arguments. Thus, by logging the submitter 

non-client errors or errors of other subsystems. In order to do program's special event ID, the event logging routine 32 

so with error handling system 10, application 12 would have recognizes that the source of the event is a particular 

the burden of having advance knowledge of the types of submitter subsystem 36. In addition, the special message 

service failures that can occur for those situations, and 4Q would indicate the source of the event and the message, 

change as the underlying service or subsystem evolves. Each client application which provides a callable "server" 

Referring to FIG. 2, there is provided an error manage- whic k may return an error code to its requesting client 

ment system of the preferred embodiment which is generally application's needs to have a unique identifier or facility 

represented by reference numeral 30. The present invention coa f • These ID's are numeric values in the range of hexa- 

automatically handles reporting of events in situations where 45 decimal 1 through FFF. In order to ensure the selected ID 

the source subsystem is different from the reporting does not conflict with those in use by any other servers, they 

subsystem, such as a client/server relationship. Due to the are recorded in a HSI file. Having selected a facility code, 

complexity and difficulty of providing the reporting sub- the server application developer uses the ID in his or her 

system with advance knowledge, as described above in message catalog definitions. 

regard to FIG. 1, the preferred embodiment identifies the 50 Since each loosely coupled service application needs a 

source of the error and obtains detailed error information at unique facility code, the developer of the application obtains 

the time the error occurs. one using the steps set forth in FIG. 3. The facility code ID 

As shown in FIG. 2, the preferred embodiment includes a development procedure is set forth in FIG. 3 which initially 

new service routine or library that is situated between the checks out the file in which the facility ID's are registered 

client application and the event logger. In particular, error 55 131. Thereafter, the codes are examined to determine those 

management system 30 comprises a service routine or in use and an unused code (1->FFF) 133 is selected. The file 

library 32 that is situated between a submitter program 34 is edited to contain selected ID's and checked back in 135. 

that logs events and a subsystem 36 that receives the logging ^ message catalog for the application error returns with 

services. For the preferred embodiment, service routine 32 is the ID specified in the message definition 137 which is 

represented by the event logging routine, submitter program 60 created using a text editor and the message catalog is 

34 is represented by the event logger, and subsystem 36 is compiled into the message DLL file 139. 

represented by the application. Service routine 32 handles When the server application is installed on the system, 

the operation of logging of the events of another subsystem. several areas of the Windows NT® registry are updated to 

Error management system 30 also includes a definition table provide information about the application. The portion of the 

38, represented by the registry, that defines the relationship 65 registry used to provide information about the application to 

between each subsystem ID that identifies a particular the event viewer is described in the Windows NT event 

subsystem and the location of its associated message cata- logging documentation which is incorporated herein by 
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reference. This information maps source name to DLL files. 
This invention includes updates to an additional area of the 
registry which provides the mapping of facility codes to 
message DLL files. 

Referring to FIGS. 4A and 4B, an operator initiates client 
application 101 written to operate in the client-server envi- 
ronment utilizing the HSI event logging class to provide 
recording of events. As part of the application's start-up 
procedure, it registers itself with HSI event logging class 
102 by calling the class's registration method and provides 
its source name. Having done this, it receives a handle to the 
vent log which may be used to perform later logging 
requests. 

The application then continues execution, possibly inter- 
acting with the user, and calling upon one or more service 
providers 103. When one of the requested services fails 104, 
the application must deal with the error. In order to report the 
error, it calls the event logging class 105 to have the error 
recorded in the event log. 

The event logging class receives the request to log the 
error number from 105 and processes it according to the 
subroutine set forth in FIG. 4B, wherein the error message 
system of the present invention checks the facility code 
portion of the error number to determine whether the facility 
code is the same as the client application 123. If the facility 
code is the same as the client application, then the current 
message ID is logged 125 and returned to subroutine in FIG. 
4A. If the facility code differs from the client application, 
then the system using source name mapping identifies the 
source using the facility code 127. Then, using the event 
viewer registry information the system is capable of finding 
the server application DLL file 129. 

These message DLL files are then loaded and the text 
associated with the error message from 141, i.e., the service 
in which the error message originated, is retrieved. The 
event logger then creates an error log entry using the 
applications reserved error number and records the error text 
in the log file 143. Thereafter, the subroutine of FIG. 4B 
returns to FIG. 4A wherein the application special process- 
ing step 106 takes place and the request for service step 103 
starts the process all over again. 

What is claimed is: 

1. An event management system for identifying and 
logging event information for a plurality of coupled 
subsystems, said system comprising: 

means for reporting an error message in response to an 

occurrence of a particular event; 
means, responsive to receiving said error message, for 

identifying a source of said error message from a 

plurality of coupled subsystems; 
means for obtaining detailed error information for said 

error message at a time frame when said particular 

event occurs, according to said source of said error 

message; 

a service routine which is capable of receiving logging 55 
event information from a particular subsystem and 
handling a logging operation of another subsystem; and 

means for providing said detailed error information to an 
event viewer. 

2. The event management system of claim 1 wherein said 
event message corresponds to an event type that includes at 
least one event type selected from the group consisting of: 
an information event type, a warning event type and an error 
event type. 

3. The event management system of claim 2 wherein said 
event type is an error event type used to report a non- 
recoverable problem. 
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4. The event management system of claim 1 further 
comprising a definition table that defines a relationship 
between an identification of a particular subsystem and a 
message catalog associated with said particular subsystem. 

5. The event management system of claim 4 wherein said 
message catalog includes a special event message for iden- 
tifying logging information that does not originate from said 
particular subsystem. 

6. A storage media for identifying and logging event 
information for a plurality of coupled subsystems, said 
storage media comprising: 

means for reporting an error message in response to an 

occurrence of a particular event; 
means, responsive to receiving said error message, for 

identifying a source of said error message from said 

plurality of coupled subsystems; 
means for obtaining detailed error information for said 

error message at a time frame when said particular 

event occurs, according to said source of said error 

message; 

a service routine which is capable of receiving logging 
event information from a particular subsystem and 
handling a logging operation of another subsystem; and 

a means for providing said detailed error information to 
an event viewer. 

7. The storage media of claim 1 wherein said event 
message corresponds to an event type that includes at least 
one event type selected from the group consisting of: an 
information event type, a warning event type and an error 
event type. 

8. The storage media of claim 7 wherein said event type 
is an error event type used to report a non-recoverable 
problem. 

9. The storage media of claim 6 further comprising a 
definition table that defines a relationship between an iden- 
tification of a particular subsystem and a message catalog 
associated with said particular subsystem. 

10. The storage media of claim 9 wherein said message 
catalog includes a special event message for identifying 
logging information that does not originate from said par- 
ticular subsystem. 

11. A method for identifying and logging event informa- 
tion for a plurality of coupled subsystems, said method 
comprising the steps of: 

(a) receiving an error message in response to an occur- 
rence of a particular event; 

(b) identifying a source of said error message from said 
plurality of coupled subsystems; 

(c) obtaining detailed error information for said re mes- 
sage at a time frame when said particular event occurs, 
according to said source of said error message; 

(d) receiving logging event information from a particular 
subsystem and handling a logging operation of another 
subsystem; and 

(e) providing said detailed error information to an event 
view. 

12. The method as recited in claim 11 wherein said step 
of obtaining retrieves said detailed error information from 
said source of said error message. 

13. The method as recited in claim 11 wherein said step 
of identifying further identifies an address, associated with 
said source, for retrieving said detailed error information, 
said step of obtaining retrieving said detailed error informa- 
tion through the use of said address. 
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